Oracle Database Appliance – (Baby Exadata?)
Oracle today announced a new database appliance product. It’s called Oracle Database Appliance (ODA). I’m not crazy about the name, but I really like the product. Here’s a picture of the one in Enkitec’s lab:
|
|
The project was code named “Comet” – thus the yellow sticky note. 😉
I really like that name better than ODA, so I think I will just stick with Comet.
Enkitec participated in the beta test program for the product and we were very impressed, particularly with the speed at which the product could be deployed and configured. There is a new tool called the “OAK Configurator” that is sort like the Exadata OneCommand for configuring the system. Keep an eye out for Karl Arao‘s upcoming post with screen shots of the tool in action.
I’m sure there will be plenty of people talking about the specs so I won’t get carried away with that. But I will tell you that it’s basically 4 terrabytes of usable storage, 2 node RAC with up to 24 cores and a SSD component that is used for improving redo write speeds (more on that later), all in a 4U chassis. Andy Colvin has already got a really good post on the hardware components that are included in the Oracle Database Appliance (along with pictures of the bits and bobs inside the chassis).
I should point out that while I have heard people refer to Comet as a “Baby Exadata”, I really don’t view it that way. That’s because it DOES NOT have separate storage and compute tiers. So there is no Exadata Smart Scan / Offloading secret sauce here. It also does not provide the ability to utilize Exadata’s Hybrid Columnar Compression. On the other hand, like Exadata, it is a pre-configured and tested system that can be dropped in a data center and be ready for use almost immediately (it took us only a couple of hours to set it up and create a database). Pretty unbelievable really.
So much like my favorite Bill Clinton quote, whether ODA is a “Baby Exadata” or not, really depends on your definition of the word “is”. It is a hardware platform that is built specifically to run Oracle databases, but it does not embed any of the unique Exadata software components. Nevertheless, it is an extremely capable platform that will appeal to wide variety of companies running Oracle databases.
And best of all, the list price for this puppy is only $50K. I predict this thing is going to sell like hot cakes!
At $50k, it’s more like ‘Preemie Exadata” 🙂
So are you on the same page as others who claim that it being pre-configured means no need for a production DBA resource?
If all that your DBA does is install and configure the software, then you won’t need a DBA 🙂
With that said, the installation of this thing is amazingly easy. Everything (Oracle binaries and installation packages) is included in one tar file, unzip, run the installer, and it goes through the entire process of setting kernel parameters, creating the oracle user account, partitioning hard drives, and installing RAC in about 10 steps. What used to take more than a week is done in a couple hours now.
Uh – not exactly… I have already been quoted today as saying:
“Anyone that thinks you can run any type of Oracle database without a knowledgeable human being is asking for trouble.”
That was taken a little out of context, but you know what I mean. Just because an Oracle database can be created in a couple of hours does not mean that you can put a mission critical system on it without a real person that knows how to ensure that it is managed appropriately (not to mention backed up).
I’d like to reinforce that: ODA does not mean that a company can run Oracle Databases without knowledgeable DBAs.
And thank you for the nice article, Kerry!
Kerry:
Do you know if $50k includes all the licenses as well? I’m assuming the answer is a firm “no”… but I needed to check and make sure before fainting.
Stewart
Kerry,
Does this list price of $50k include any Oracle licensing or is it “just” for the hardware.
It’s hard to believe that Oracle would throw in the licensing for a 2-node RAC and 24 core system at this Walmart-special rate…
Chris 🙂
Sorry for the confusion. The $50K is the hardware list. Licenses are per normal Oracle price list. There is no special software like the storage software on Exadata though. So if you already have enough DB cores licensed and you want to move your DB to this platform you can move the licenses.
[…] Exadata, depending on your definition of the word 'is.'" Oracle, Database Read the full post on Oracle Technology Network… Share […]
Hi all
What will happen when the time comes to upgrade/patch this ODA…is it a closed black box ?
Paul,
It is not a closed black box. However, since it’s an “engineered system”, Oracle is providing a patching methodology that is unique to the platform via the oakcli tool. Sounds similar to Exadata patching to get firmware and software in one session. The docs talk about Oracle Appliance Manager but the syntax looks like this:
./oakcli update -patch 2.1.0.0.1
We have not actually done one yet in our lab but I’m sure Andy Colvin will probably blog about the process soon at:
http://blog.oracle-ninja.com/
Kerry
This is oracle nosql right, with R
No – this is regular Oracle database using SQL.
Kerry
I was looking very seriously at the ODA for an upcoming hardware refresh. The most attractive feature for me is the fact that you can license as few as 4 CPUs (2 per box or 4 in a RAC One Node config). What killed it for me was this: http://docs.oracle.com/cd/E22693_01/doc.21/e22692/undrstd.htm#CIHIHFJE
“At the time of this release, Oracle Appliance Manager Patching does not support rolling patching. The entire system must be taken down and both servers patched before restarting the database.”
Without rolling patches, I’m rolling my own. If I need more CPUs, I’ll connect a new commodity server to my storage array with more CPUs in it & pay the difference for licensing.
T.J.,
No patches even exist for the ODA at this point so it’s a bit of a mute point. That said, if you are running a system that absolutely can not afford any maintenance windows then you probably should be paying a lot more money for it than what the ODA costs. The fact that Oracle has not announced a rolling patch strategy for this machine “yet” is a nit in my opinion and is probably something that will be addressed in fairly short order. If it’s an absolute requirement to never have any down time then you might consider buying two ODA’s and using Dataguard. This would allow you to do “standby first patching” which means virtually no application downtime. However, every solution has it’s trade off’s so it’s best to understand your requirements and architect a solution that fits in your budget and meets your most important needs. The ODA shines in a couple of areas:
1. Cost – I don’t believe there is any way you can build your own cheaper. We went through the exercise of pricing competitive components and couldn’t come up with a way to do it for less money.
2. Time – Building out your own RAC cluster takes time which translates to money. We’ve built out a bunch of two node RAC clusters over the last several years and it takes some time. Our experience has been that to do a thorough job generally takes a couple of weeks. With ODA the configuration can be done in a day.
3. Risk mitigation – The biggest advantage of ODA in my opinion is that you don’t have worry if you, or your staff, or your consultants have thoroughly tested the newly created environment. The last thing you want is a system that becomes unstable under load after you have put it in production. This can and does happen due to various components not working well together or not being configured to work well together.
Clearly you will have more flexibility if you “roll your own” because you can do anything you want. But you will be trading the advantages provided by that approach against the advantages provided by a prebuilt system. That is to say, the custom system will probably cost more and take longer and introduce more risk. Most technical solutions involve trade offs of some type.
You may wonder why I would be arguing against building from scratch since I work for a consulting company that typically gets paid by the hour to do this kind of work. The answer is that the vast majority of RAC systems we’ve helped customers build over the last several years would be nicely handled by ODA. So I don’t really expect we’ll be building too many more two node RAC clusters.
Kerry,
Thank you for your response. I certainly appreciate the depth and breadth of the experience behind your comments and recommendations. I agree with your assertion at Hotsos that the industry is beginning to lean towards engineered systems, but for my situation, it just doesn’t make sense yet.
As my employer continues to grow, downtime becomes less and less tolerable. For our part, we are using DataGuard in order to maintain a DR site across town, so we’re looking at 2 identical hardware setups as it is (presently, we’re single instance). I see what you’re saying about patching the standby, switching over, patching the primary, and switching back. Is this possible with ODA? Your post only mentions one box, so I’m assuming this is only a theoretical solution. Beyond the theory, the risk there for me is whether our services can respond within SLAs when they’re connected to a database that’s on the opposite end of a metro E connection. What I want is on-site redundancy, and I can get that with RAC One Node without licensing a 2nd box, thanks to the 10 day rule (IF I can manage to stay off that box for 10 days, of course). Regarding your list of advantages,
1. Cost – I agree completely when only looking at hardware – The ODA box is priced quite competitively. A full examination of the cost requires more than just hardware though. For the size of individual server I’m after (I’m looking for as few cores and as much RAM as possible), the cost difference is insignificant compared to the gain in flexibility. I’m essentially out of time to investigate options such as your suggestion to patch the standby & roll to it, as the tax advantage of capital improvements diminishes significantly in 2012.
2. Time – Right on again, but flexibility beats the cost again for me.
3. Risk mitigation – The “It Just Works” factor is huge, but the known quantity of no rolling patches and no commitment that it will change or timeline as to when that will change is a larger risk for me. I’m moving from single instance to RAC One Node in either case, so why wouldn’t I choose to take advantage of the redundant server for rolling patches?
Thanks again for your input. In considering my response to you, I am convinced that ODA is a viable option, although I still don’t see it as my first choice.
-T. J.
The discussion on Oracle-L this week got me thinking about this post again. Your point about time is all the better taken now, as I’ve finally had an opportunity over the past 2 weeks to play in our new environment. Most of the hardware arrived before the end of 2011. It was installed by the end of January, and due to competing priorities of our SA, not fully configured until Feb 18. Then came Orion, then installation and so on and so on. Depending on the priority one places on the time to stand up an environment, this factor can indeed make ODA an attractive option.
I still see roll-your-own was still the best option in our case, but those are due largely to psychological/political factors within our organization.
Thanks again for your insights, and I hope to see you at Hotsos next week!
-T. J.
Is there any references using ODA now ?
Hi all,
we are facing really poor single thread performance of ODA with 6-core Intel Xeon
processors X5675. 3.06 GHz.
Can somebody share output of
select PVAL1 from aux_stats$ where pname=’CPUSPEEDNW’;
THX
Ralf
Hi Moosandl,
Yes – this is a known (but unpublished) bug (bios related). The bios is supposed to be fixed in the next ODA bundle patch set. You should open an SR and support should be able to help you fix the problem. CPUSPEEDNW will be around 675 with the bug and should be around 2700 after the fix.
Kerry
Hi Kerry,
You are right, it should be fixed with patchset 2.1.0.3.0. In the meantime, we received a temporary patch, which accelerated our benchs by 400%. I received (but cannot validate because of missing access) the information that AUX_STAT$.CPUSPEEDNW is still the same.
Ralf
The fix will not automatically change the setting of CPUSPEEDNW. You’ll have to re-gather System Stats. I tend to like NWL stats which can be gathered like so.
execute dbms_stats.gather_system_stats(‘noworkload’);
I am sure, your suggestion will work, but I cannot verify it because of missing access to ODA.
execute dbms_stats.delete_system_stats;
worked for me.
Now, ODA shows around 2900 MHz at AUX_STAT$.CPUSPEEDNW
Ralf
Moosandl,
The fix has been officially released for the ODA. 2.1.0.3.0 (patch #13622348) was released today. Check MOS note #888888.1 for details. If you’re already running 2.1.0.2.0, then you don’t have to install the Oracle patch. It’s the same as in 2.1.0.2.0 (the January 2012 CPU).